Management of care area transitions of intravenous infusions

ABSTRACT

An infusion device providing an in-progress infusion of at least one of a drug or a fluid consistent with one or more parameters of a first care area in a hospital can be transitioned to a second care area of the hospital. Details of the in-progress infusion can be compared against one or more second parameters defined for the second care area, and a compatibility determination can be made between the in-progress infusion and the one or more second parameters defined for the seconds care area. A handling mode of the in-progress infusion in the second care area can be selected based on the compatibility determination, and the in-progress infusion can be resolved consistent with the selected handling mode. Related apparatus, systems, techniques and articles are also described.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.13/830,132 filed on Mar. 14, 2013. The disclosure of which is herebyincorporated by reference in its entirety.

TECHNICAL FIELD

The subject matter described herein relates to infusion devices and usesthereof in a treatment setting, such as for example a hospital. Inparticular, the current subject matter is directed to management ofinfusions of drugs, fluids, and the like as a patient is transitionedbetween different care areas within the treatment setting.

BACKGROUND

Patient care in hospitals and other treatment settings can includeactive monitoring of various physiological parameters of a patient,especially with regard to infusion of various types of fluids deliveredby one or more infusion devices.

Dose error reduction software (DERS) can be used with infusion devices(e.g. an infusion pump systems) for delivery of drugs, fluids, and othertherapeutic substances (hereinafter referred to generally as “drugs”). Ageneral goal of DERS is improvement in the safety and clinical utilityof infusing intravenous drugs and fluids. A typical DERS system may beconfigured to allow creation of customized care areas. As used herein,the term “care area” can refer to a physical location or multiplelocations within a hospital or other clinical care setting (hereinafterreferred to generically as a “hospital”). For example, a care area canbe defined as a neonatal intensive care unit (NICU), an intensive careunit, a trauma ward, etc., and such designations can be tied to physicallocations (e.g. constrained within a specific location or locationswithin the hospital), or more generally to refer to a general class ofpatient, such as for example adult medical/surgical. Within a care area,one or more settings, such as for example custom device configurations,minimum and maximum hard and or soft limits per drug or fluid to bedelivered, and the like may be established for an infusion device.

SUMMARY

In one aspect, a method includes transitioning an infusion deviceproviding an in-progress infusion of at least one of a drug or a fluidconsistent with one or more parameters of a first care area in ahospital to a second care area of the hospital, comparing details of thein-progress infusion against one or more second parameters defined forthe second care area, making a compatibility determination between thein-progress infusion and the one or more second parameters defined forthe seconds care area, selecting a handling mode of the in-progressinfusion in the second care area based on the compatibilitydetermination, and resolving the in-progress infusion consistent withthe selected handling mode.

In optional variations, one or more of the following additional featurescan be added in any feasible combination. The making of thecompatibility determination can include identifying whether thein-progress infusion is a good match, a partial match, a bad match, or ablocked infusion in the second care area. The compatibilitydetermination can include identifying that the infusion is the goodmatch, the good match can include a match between a drug/fluidinformation and a usage context for the in-progress infusion and the oneor more second parameters, and the handling mode can includetransitioning the infusion device from a first profile for the firstcare area to a second profile for the second care area while thein-progress infusion is allowed to continue. Alternatively, thecompatibility determination can include identifying that the infusion isthe partial match, the partial match can include a match between adrug/fluid information and a usage context for the in-progress infusionand the one or more second parameters but one or more in-progressinfusion parameters of the in-progress infusion falling outside of anallowable range specified in the one or more second parameters, and thehandling mode can include allowing the transitioning of the infusiondevice from a first profile for the first care area to a second profilefor the second care area to complete and for the in-progress infusion tocontinue under its current one or more in-progress infusion parameters.In another alternative, the compatibility determination can includeidentifying that the infusion is the bad match, the bad match caninclude no match between the drug/fluid information and a usage contextfor the in-progress infusion and the one or more second parameters, andthe handling mode can include allowing the in-progress infusion tocomplete in accordance with a first profile for the first care areabefore the transitioning of the infusion device to the second care area.In still another alternative, the compatibility determination caninclude identifying that the infusion is the blocked infusion, theblocked infusion can include the at least one drug or fluid beingdesignated as non-transferable in the first care area, and the handlingmode can include at least one of canceling the transitioning to thesecond care area and allowing completion of the transitioning whilecanceling the in-progress infusion.

Computer program products are also described that comprisenon-transitory computer readable media storing instructions, which whenexecuted one or more data processor of one or more computing systems,causes at least one data processor to perform operations herein.Similarly, computer systems are also described that may include one ormore data processors and a memory coupled to the one or more dataprocessors. The memory may temporarily or permanently store instructionsthat cause at least one processor to perform one or more of theoperations described herein. In addition, methods can be implemented byone or more data processors either within a single computing system ordistributed among two or more computing systems. Such computing systemscan be connected and can exchange data and/or commands or otherinstructions or the like via one or more connections, including but notlimited to a connection over a network (e.g. the Internet, a wirelesswide area network, a local area network, a wide area network, a wirednetwork, or the like), via a direct connection (wired or peer-to-peerwireless) between one or more of the computing systems, etc.

The details of one or more variations of the subject matter describedherein are set forth in the accompanying drawings and the descriptionbelow. Other features and advantages of the subject matter describedherein will be apparent from the description and drawings, and from theclaims.

DESCRIPTION OF DRAWINGS

FIG. 1 shows a diagram illustrating a generalized representation of ahospital dataset;

FIG. 2 shows a process flow diagram illustrating features of a method;and

FIG. 3 shows a diagram illustrating a computing landscape including amodular medical device system.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

One or more custom configurations and drug/fluid limits associated withthe care areas in a hospital may, in some examples, be created using aDERS software application or module and then transferred to the variousinfusion devices or infusion systems including multiple infusion devicesthat are located in the hospital. An infusion system may include one ormore infusion devices, such as for example single syringes, multichannelsyringes, large volume parenteral (LVP) infusion pumps or other devices,patient-controlled analgesia (PCA) devices, or other infusion or enteraldelivery systems or the like.

As part of the infusion setup process, the end user (for example anurse) can be required to select an appropriate, current care area for apatient. As noted above, the care area can be based on one or more of aphysical location (e.g. ICU, NICU, trauma, surgery, etc.), a patienttype (e.g. adult medical/surgical), and the like depending on how thecare areas are partitioned or otherwise defined within the hospital.

An issue that frequently arises with DERS systems in a hospitalenvironment involves handling of ongoing infusions when a patient istransferred from a first care area to a second care area. One approachto dealing with infusions that are in process or otherwise ongoing whena patient is transferred from the first care area to the second carearea is to force a shutdown of the infusion system. When the system issubsequently powered on, infusions consistent with one or moreparameters or settings defined for the second care area can be selectedby the end user (e.g. a nurse).

A hard shutdown approach as discussed in the preceding paragraph can beeffective in assuring that each infusion occurring after transition tothe second care area is consistent with parameters, settings, etc. thatare appropriate for the second care area. However, a hard shutdown andrestart of infusions based on a new set of parameters, settings, etc.appropriate to the second care area can be very disruptive of theinfusion process. Each infusion must be stopped, reprogrammed, andrestarted, which can result in delay, additional clinician (e.g. nurse,other end user, etc.) time, and potential negative clinical consequences(for example for drugs for which an interruption in delivery of even avery brief duration can alter the pharmacological effect). Additionally,a drug or fluid infusion initiated in the first care area might not beavailable under the parameters established for the second care area towhich the patient has been transitioned. If the clinically appropriateapproach would be to continue to infuse a given drug or fluid accordingto the parameters of the first care area until the current dosing ofthat drug of fluid has completed, the end user would be required eitherto delay switching the patient from the first care areas to the secondcare area for all of the currently ongoing drug or fluid infusions forthat patient, or to switch the care area to the second care area andcontinue delivery of the given drug or fluid independently of the DERSsystem. Neither of these options is desirable from a patient care andsafety standpoint.

Another approach to dealing with infusions that are ongoing duringtransition of a patient from a first care area to a second care areawould be to allow the care area change, but to allow all infusions tocontinue under the settings of the previous care area until completed.This approach can be appropriate for some drugs or fluids, but can alsobe very inappropriate or even dangerous for other drugs or fluids, forexample if the parameters, library of drugs and fluids available, dosinglimits, doing methods, or the like that are set for the second care areapresent a conflict with those of the first care area.

To address these and potentially other difficulties with currentlyavailable solutions, implementations of the current subject matter canprovide capabilities that allow for hospital management, end users (e.g.clinicians, nurses, etc.) caring for a patient, etc. to seamlessly andsafely transition a patient from a first care area to a second care areawithout requiring that one or more infusion devices providing drugs,fluids, etc. to the patient be power cycled, reprogrammed, etc.

Consistent with implementations of the current subject matter, ongoinginfusions can be classified according to one or more algorithms or othercriteria to allow continuation of an ongoing, in-progress infusion whereappropriate, or to force discontinuation based on the hospital's bestpractices or other parameters.

In some implementations, a list of care areas can be contained in ahospital dataset, which can, for example, be stored in one or more datarepositories accessible via one or more wired or wireless communicationlinks with one or more infusion devices. Alternatively, a hospitaldataset can be stored and updated at the individual infusion devices,for example by direct input via a user interface, by data transfer froma connected storage device, or the like. FIG. 1 shows a generalizedrepresentation of a hospital dataset 100 that includes a list 102 ofcare areas. Each care area 104 included in the list 102 contains general(non-drug/fluid specific) care-area-specific configuration settings 106and a list of drugs/fluid-specific settings 110.

The general care-area-specific configuration settings 106 can apply toall infusions administered in that care area, and are not specific to aparticular drug or fluid. Typical examples of general care-area-specificconfiguration settings 106 can include an air-in-line limit (e.g. amaximum allowable air bubble size) or an occlusion pressure limit (e.g.a maximum allowable line pressure).

As shown in FIG. 1, each drug/fluid entry in the list ofdrugs/fluid-specific settings 110 can include several types ofinformation. The drug/fluid information 112 contains information thatunambiguously establishes the drug or fluid and its form. Examples ofthis type of information include the drug or fluid name andconcentration (if applicable). A usage context 114 contains informationthat defines the particular clinical context for the use of this drug orfluid. Examples of this type of information can includetherapy/indication, infusion device type (LVP, syringe . . . ), or thelike. Together, the drug/fluid information 112 and usage context 114establish a clinical context for applying DERS limits and settings fordelivery of that specific drug in a given care area. These limits andsettings are contained in a drug/fluid settings entry 116 for each drugor fluid as shown in FIG. 1.

When an end user programs an infusion to be performed by an infusiondevice, the end user can be required (for example by a user interface ofor associated with the infusion device) to enter or select the necessaryinformation to identify the correct drug/fluid information and usagecontext for the infusion to be performed. One or more DERS limits toprotect the programming session can be selected such that the correctdrug-dependent settings are applied when the infusion starts.

Subsequent to initial programming of an infusion device, during whichsettings and limits from a first care area in which the infusion deviceis being operated are applied, implementations of the current subjectmatter enable a seamless transition of the infusion device, and thepatient receiving an infusion from the infusion device, from a firstcare area to a second care area “on the fly.” In other words, no restartof the system or interruption of ongoing infusions is necessary, exceptas mandated by the general care configuration settings 106 of the secondcare area to which the patient and the infusion device are beingtransitioned. Compatibility between a particular ongoing infusion andthe parameters of the second care area can be determined, and based onthis compatibility, (e.g. Good Match, Partial Match, Bad Match andBlocked, which are described in more detail below) the change in carearea from the first care area to the second care area can be allowed ordisallowed as appropriate. Optionally, if conflicts between an ongoinginfusion and parameters of the second care area are detected, the enduser can be notified of such conflicts, for example by a message shownon a display screen that presents a user interface, by activation of avisual or audio alarm, or the like.

As noted above, in reference to FIG. 1, care areas within a hospital caninclude care-area specific general care area configuration settings 106as well as a list 110 of available drugs, fluids, etc. that can bedelivered to patients within that care area subject to parametersspecified for that care area 104, for example in a hospital dataset 100.These parameters can optionally include one or more of the followingfeatures. Within a specific care area, optionally within one or morecare areas or even within each care area within the hospital, certaindrugs or fluids can be designated as “non-transferable,” indicating thatthey are not to be used in any other care area. An end user is able toselect or change a care area to which the infusion device and associatedpatient are to be transitioned based on the care areas available in thehospital dataset 100. A user interface can be provided to allow the userto initiate a change in care area (e.g. from a first, current care areato a second, different care area) at any time.

When an infusion device (and its associated patient) is transitionedfrom a first care area to a second care area, implementations of thecurrent subject matter can detect conflicts between an active infusionand one or more of the following parameters that can be defined as partof the general care area configuration settings 106 or the entries inthe drug/fluid list 110 of the second care area: restricted use (e.g.the drug or fluid is not transferrable to the second care area),drug/fluid information and usage context match, DERS limits, doselimits, rate limits, care area configuration limits and settings, andthe like.

Based on any differences between these parameters for the first carearea and the second care area, a response can be generated for a givenongoing (e.g. in-progress during the transition from the first care areato the second care area) infusion that reflects a good match, a partialmatch, a bad match, a blocked infusion, etc.

An ongoing infusion being transferred from a first care area can beconsidered a good match with the second care area if a match for theinfusion's drug/fluid information 112 and usage context 114 is found inthe parameters defined for the second care area and if all infusionparameters fall within the allowable range specified for the second carearea, both according to the general care area-specific configurationsettings 106 and the entry for the specific drug or fluid in thedrug/fluid list 110 specific for the second care area.

If a good match infusion is indicated or otherwise determined, theinfusion device can be immediately transitioned from the profile for thefirst care area to a new profile for the second care area and can alsoimmediately apply all configuration settings (e.g. both general anddrug/fluid-specific) from the second care area. The end user can repeat(e.g. recall the original programming parameters) for this infusion whenit completes, or resume (recall the latest running infusion parameters)if it was interrupted.

An ongoing infusion being transferred from a first care area canconsidered a partial match with the second care area if a match for theongoing infusion's drug/fluid information and usage context is found inthe parameters defined for the second care area but one or moreparameters of the ongoing infusion fall outside the allowable rangespecified for the second care area, either from the general care areaconfiguration settings 106 or the specific drug/fluid settings 116 forthe second care area.

If a partial match infusion is indicated or otherwise determined, theinfusion device can complete the transition from the first care area tothe second care area. The end user can be notified (e.g. via a userinterface or other communication approaches) that the DERS limits arebeing violated. While the infusion is running, the end user is allowedto modify the infusion parameters, and such modifications are validatedagainst the limits defined in the second care area. The end user can beallowed to repeat or resume this infusion. However all parameters thatviolate limits in the second care area can be required to be broughtinto compliance.

An ongoing infusion being transferred from a first care area can beconsidered a bad match with the second care area if no match for theinfusion's drug/fluid information 112 and usage context 114 is found inthe parameters defined for the second are area.

If a bad match is indicated or otherwise determined, the infusion can beallowed to complete under the first care area. While the infusion isrunning, the end user can be permitted to modify the infusionparameters, which are validated against the limits defined for the firstcare area. The end user can repeat or resume this infusion. However allparameters that violate limits in the second care area can be requiredto be brought into compliance.

An ongoing infusion being transferred from a first care area can beblocked with respect to a second care area if drug or fluid has beendesignated as “non-transferable” in the first care area. If a blockedinfusion is indicated or otherwise determined, the care area transitioncan be canceled for the infusion or for an entire infusion system thatthe infusion device is part of. Alternatively, the transition from thefirst care area to the second care area can be allowed but all blockedinfusions can be permanently stopped. An end user can be prompted (e.g.via a user interface or the like) to decide which course of action totake. Alternatively, a default setting can be established such that theinfusion system automatically selects one or the other approach in apredetermined manner (optionally with appropriate user notification).

Consistent with one or more implementations of the current subjectmatter, FIG. 2 shows a process flow chart 200 illustrating features of amethod. At 202, an infusion device providing an in-progress infusion ofa drug or fluid consistent with parameters of a first care area in ahospital is transitioned to a second care area. Details of thein-progress infusion are compared at 204 against a set of parametersdefined for the second care area. In some implementations of the currentsubject matter, the parameters defined for the second care area caninclude general care area-specific configuration settings 106 for thesecond care area and specific drug/fluid settings 116 for the secondcare area. A compatibility determination is made at 206 between thein-progress infusion and the parameters defined for the second carearea, and at 210, a handling mode of the in-progress infusion in thesecond care area is selected based on the compatibility determination.At 212, the in-progress infusion is resolved consistent with thehandling mode.

The handling mode can include one those described above, for example fora good match, partial match, bad match, or blocked compatibilitydetermination as determined at 206. The resolving of the in-progressinfusion can optionally occur by applying the operations specified inthe handling mode.

Features of the current subject matter can be applicable for asystem-wide care area change for a centrally controlled system ofinfusion channels, such as for example a central unit that providespower, a unified user interface for controlling one or more infusionchannels (e.g. separate pumps or infusion device, etc.). Such a systemcan optionally include a monolithic single or multi-channel device, or amodular system of attachable and detachable infusion devices.

An alternative but related scenario occurs in the case of a modularinfusion system where each infusion module has the ability to functionindependently, or may be attached to an aggregate system and function asan integrated part of it. In this situation, an implicit change in carearea can occur when the module with its active infusion and care area isattached to the larger system, which has its own running infusions andcare area. The described resolution process can be used to assimilatethe new infusion into the aggregate system, with some modifications. Inparticular, the user choices for a blocked infusion might be to (1)remove the module or (2) to leave it and have the system stop theinfusion.

One skilled in the art would recognize that the algorithms andapproaches described above is just one example of how the system couldmanage care area changes. The system could readily support multiplealgorithms. These algorithms could even be customizable by theinstitution to meet their specific patient care needs. It is alsopossible to find middle ground in the system response to bad or partialmatches: some hybrid of the first care area settings and the second carearea settings could be used, rather than the whole of one or the other.

The transitioning from the first care area to the second care area canbe performed in response to a user input identifying to an infusiondevice or infusion system including an infusion device that thetransition is occurring. Alternatively, in the case of a modularinfusion device that can be removed from a first central system in thefirst care area, moved with a patient to a second care area, andreattached to a second central system in the second care area, thetransition can occur through communication of the modular diffusiondevice with the second central system to indicate that the modulardevice is now in the second care area. In yet another alternative, oneor more location indication devices, such as for example a globalpositioning system (GOS) signal or other locator beacon, a wirelesslocation signal of some other kind, etc., can be received by theinfusion device to indicate that the transition has occurred.

Features that can be included in various implementations of the currentsubject matter can be understood in reference to the following,non-limiting, example use cases.

In a first example, a pump (e.g. an infusion device) is configured in a“Medical/Surgical” care area, where it is attached to a patient anddelivering the drug heparin at a concentration of 25,000 units per 250mL in a “High Dose” therapy mode at 900 units/h. The maximum dose limitis 1000 unit/h. The patient is transferred from the “Medical/Surgical”care area to a second car area: the “ICU” care area. Upon arrival theICU care area, the end user (e.g. a nurse or other clinician) switchesthe pump's current care area from “Medical/Surgical” to “ICU.”

A scan of drugs and fluids assigned to a “ICU” care area profile findsan entry for heparin 25000 units/250 mL in the high dose therapy withdosing units of units/h (all the same as the parameters in theMedical/Surgical care area). The system does determine that the DERSlimits for the entry in the “ICU” care area are more strict, in thiscase, 950 unit/h, but that the current infusion falls within theguidelines. The system determines that this entry is compatible with thecurrent infusion (and is therefore a “good match”) and so updates theinfusion with the data from the “ICU” profile entry and successfullycompletes the switch to the “ICU” care area without further user action.

In a second example, a pump (e.g. an infusion device) is configured in a“Medical/Surgical” care area, where it is attached to a patient anddelivering the drug heparin at a concentration of 25,000 units per 250mL in a “High Dose” therapy mode at 900 units/h. The patient istransferred from the “Medical/Surgical” care area to an “ICU’ Care Area.Upon arrival the ICU clinician switches the pump's current Care Area to‘ICU’.

A scan of drugs and fluids assigned to a “ICU” care area profile findsan entry for heparin 25,000 units per 250 mL in the high dose therapywith dosing units of units/h (all the same as the parameters in theMedical/Surgical care area). However, the system determines that theDERS limits for the entry in the “ICU” care area are more strict thanthose of the Medical/Surgical care area, in this case, 800 unit/h. Assuch, the current infusion falls outside these guidelines. The systemdetermines that this entry is compatible with the current infusion(however, as only a partial match) and so updates the infusion with thedata from the “ICU” entry and successfully completes the switch to the“ICU” care area without further user action required. Upon thetransition from the first care area (“Medical/Surgical”) to the secondcare area (“ICU”), the system allows the infusion to continue to operatewith the current infusion parameters. Additional user action is notrequired. However the infusion is conspicuously identified by the systemuser interface as infusing outside the DERS limits for the ICU carearea. The next time the infusion is accessed for programming, the enduser is required to bring the infusion parameters into compliance withthe ICU care area settings.

An infusion device can be part of an infusion system as noted above.Implementations of the current subject matter of the current subjectmatter are not restricted to any specific type of infusion devices orinfusion systems.

FIG. 3 is a system diagram illustrating an example of a computinglandscape 300 within a healthcare environment such as a hospital.Various devices and systems, both local to the healthcare environmentand remote from the healthcare environment, can interact via at leastone computing network 305. This computing network 305 can provide anyform or medium of digital communication connectivity (i.e., wired orwireless) amongst the various devices and systems. Examples ofcommunication networks include a local area network (“LAN”), a wide areanetwork (“WAN”), and the Internet. In some cases, one or more of thevarious devices and systems can interact directly via peer-to-peercoupling (either via a hardwired connection or via a wireless protocolsuch as Bluetooth or WiFi). In addition, in some variations, one or moreof the devices and systems communicate via a cellular data network.

In particular, aspects of the computing landscape 300 can be implementedin a computing system that includes a back-end component (e.g., as adata server 310), or that includes a middleware component (e.g., anapplication server 315), or that includes a front-end component (e.g., aclient computer 320 having a graphical user interface or a Web browserthrough which a user may interact with an implementation of the subjectmatter described herein), or any combination of such back-end,middleware, or front-end components. A client 320 and server 310, 315are generally remote from each other and typically interact through thecommunications network 310. The relationship of the clients 320 andservers 310, 315 arises by virtue of computer programs running on therespective computers and having a client-server relationship to eachother. Clients 320 can be any of a variety of computing platforms thatinclude local applications for providing various functionality withinthe healthcare environment. Example clients 320 include, but are notlimited to, desktop computers, laptop computers, tablets, and othercomputers with touch-screen interfaces. The local applications can beself-contained in that they do not require network connectivity and/orthey can interact with one or more of the servers 310, 315 (e.g., a webbrowser).

A variety of applications can be executed on the various devices andsystems within the computing landscape such as electronic health recordapplications, medical device monitoring, operation, and maintenanceapplications, scheduling applications, billing applications and thelike.

The network 310 can be coupled to one or more data storage systems 325.The data storage systems 325 can include databases providing physicaldata storage within the healthcare environment or within a dedicatedfacility. In addition, or in the alternative, the data storage systems325 can include cloud-based systems providing remote storage of data in,for example, a multi-tenant computing environment. The data storagesystems 325 can also comprise non-transitory computer readable media.

Mobile communications devices (MCDs) 330 can also form part of thecomputing landscape 300. The MCDs 330 can communicate directly via thenetwork 305 and/or they can communicate with the network 305 via anintermediate network such as a cellular data network. Various types ofcommunication protocols can be used by the MCDs 330 including, forexample, messaging protocols such as SMS and MMS.

Various types of medical devices 340 can be used as part of thecomputing landscape 300. For example, the landscape can include comprisevarious systems/units for delivering fluid (including medication) to apatient. On particular type of medical device 340 is an infusion module340A, which is an example of an infusion device consistent with thedescription above. The infusion modules 340A can include various typesof infusion pumps including peristaltic infusion pumps, large volumeinfusion pumps, and syringe pumps. The infusion modules 340A can bedirectly coupled to the network 305 and/or they can be coupled to amedical device 340 which is, in turn, coupled to the network 340.

The medical devices 340 can comprise, unless otherwise specified, anytype of device or system with a communications interface thatcharacterizes one or more physiological measurements of a patient and/orthat characterize treatment of a patient. In some cases, the medicaldevices 340 communicate via peer to peer wired or wirelesscommunications with another medical device 340 (as opposed tocommunicating with the network 305). For example, the medical device 340can comprise a bedside vital signs monitor that is connected to othermedical devices 340, namely a wireless pulse oximeter and to a wiredblood pressure monitor. One or more operational parameters of themedical devices 340 can be locally controlled by a clinician, controlledvia a clinician via the network 305, and/or they can be controlled byone or more of a server 315, 320, a client 325, a MCD 330, and/oranother medical device 340. A medical device 340 including one or moreinfusion modules 340A is an example of an infusion system consistentwith the descriptions above.

The computing landscape 300 can provide various types of functionalityas may be required within a healthcare environment such as a hospital.For the medical devices 340 can provide data characterizing one or morephysiological measurements of a patient and/or treatment of a patient(e.g., medical device 340 can be an infusion management system, etc.).The data generated by the medical devices 340 can be communicated toother medical devices 340, the servers 310, 320, the clients 320, theMCDs 330, and/or stored in the data storage systems 325.

The computing landscape 300 can also include at least one medicationordering system 345. The medication ordering system 345 is coupled tothe network and enables orders (e.g., prescriptions, etc.) to begenerated and monitored. The medication order system 345 can beaccessed, for example, via the one of the clients 320 and MCDs 330 viathe application server 315. The medication ordering system 345 canspecify a plurality of medications and/or other fluids to be infusedinto a patient over a pre-defined period of time and according to apre-defined sequence via at least one infusion module 340A. This orderscan be stored in the data storage 325 and/or pushed out to other clients320, an MCD 330, and/or one or more of the medical devices 340. In somecases, caregivers alter the timing and sequence of such medicationdelivery based on reactions from the patient (as measured by variousphysiological sensors, etc.).

One more of the medical devices 340 (such as infusion modules 340A) canmonitor an amount of fluid (e.g., medication, etc.) delivered to apatient. Fluids delivered to patients are referred to herein asinfusions. Unless otherwise specified, references herein to medicationsshould also be construed to include non-medication fluids (e.g., blood,saline, etc.) for delivery to a patient via an infusion module 340A.

As noted above, containers housing fluids such as medication often varyfrom the volumes ordered by a pharmacist/clinician. Asoftware-implemented infusion management platform 350 can be providedthat includes a graphical user interface for tracking and monitoringinfusions for one or more patients. The infusion management platform 350communicates with the infusion modules 340A via the network 305. Theinfusion modules 340A can directly or indirectly provide variousattributes relating to a particular infusion to the infusion managementplatform 350 (e.g., patient identifier, medication container identifier,medication type, rate of medication administration, infusion moduleidentifier, etc.). Such attributes can be provided, for example, viamessages sent from the infusion modules 340A. In some cases, theinfusion management platform 350 receives medication orders from themedication ordering system 345 and then associates such orders withparticular infusion modules 340A and/or particular patients (who arelater associated with the infusion modules 340A).

One or more aspects or features of the subject matter described hereinmay be realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations may include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device (e.g., mouse, touch screen, etc.), andat least one output device.

These computer programs, which can also be referred to programs,software, software applications, applications, components, or code,include machine instructions for a programmable processor, and can beimplemented in a high-level procedural and/or object-orientedprogramming language, and/or in assembly/machine language. As usedherein, the term “machine-readable medium” refers to any computerprogram product, apparatus and/or device, such as for example magneticdiscs, optical disks, memory, and Programmable Logic Devices (PLDs),used to provide machine instructions and/or data to a programmableprocessor, including a machine-readable medium that receives machineinstructions as a machine-readable signal. The term “machine-readablesignal” refers to any signal used to provide machine instructions and/ordata to a programmable processor. The machine-readable medium can storesuch machine instructions non-transitorily, such as for example as woulda non-transient solid state memory or a magnetic hard drive or anyequivalent storage medium. The machine-readable medium can alternativelyor additionally store such machine instructions in a transient manner,such as for example as would a processor cache or other random accessmemory associated with one or more physical processor cores.

These computer programs, which can also be referred to as programs,software, software applications, applications, components, or code,include machine instructions for a programmable processor, and can beimplemented in a high-level procedural language, an object-orientedprogramming language, a functional programming language, a logicalprogramming language, and/or in assembly/machine language. As usedherein, the term “machine-readable medium” refers to any computerprogram product, apparatus and/or device, such as for example magneticdiscs, optical disks, memory, and Programmable Logic Devices (PLDs),used to provide machine instructions and/or data to a programmableprocessor, including a machine-readable medium that receives machineinstructions as a machine-readable signal. The term “machine-readablesignal” refers to any signal used to provide machine instructions and/ordata to a programmable processor. The machine-readable medium can storesuch machine instructions non-transitorily, such as for example as woulda non-transient solid state memory or a magnetic hard drive or anyequivalent storage medium. The machine-readable medium can alternativelyor additionally store such machine instructions in a transient manner,such as for example as would a processor cache or other random accessmemory associated with one or more physical processor cores.

With certain aspects, to provide for interaction with a user, thesubject matter described herein can be implemented on a computer havinga display device, such as for example a cathode ray tube (CRT) or aliquid crystal display (LCD) monitor for displaying information to theuser and a keyboard and a pointing device, such as for example a mouseor a trackball, by which the user may provide input to the computer.Other kinds of devices can be used to provide for interaction with auser as well. For example, feedback provided to the user can be any formof sensory feedback, such as for example visual feedback, auditoryfeedback, or tactile feedback; and input from the user may be receivedin any form, including, but not limited to, acoustic, speech, or tactileinput. Other possible input devices include, but are not limited to,touch screens or other touch-sensitive devices such as single ormulti-point resistive or capacitive trackpads, voice recognitionhardware and software, optical scanners, optical pointers, digital imagecapture devices and associated interpretation software, and the like.

The subject matter described herein may be implemented in a computingsystem that includes a back-end component (e.g., as a data server), orthat includes a middleware component (e.g., an application server), orthat includes a front-end component (e.g., a client computer having agraphical user interface or a Web browser through which a user mayinteract with an implementation of the subject matter described herein),or any combination of such back-end, middleware, or front-endcomponents. The components of the system may be interconnected by anyform or medium of digital data communication (e.g., a communicationnetwork). Examples of communication networks include a local areanetwork (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system may include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

The subject matter described herein can be embodied in systems,apparatus, methods, and/or articles depending on the desiredconfiguration. The implementations set forth in the foregoingdescription do not represent all implementations consistent with thesubject matter described herein. Instead, they are merely some examplesconsistent with aspects related to the described subject matter.Although a few variations have been described in detail above, othermodifications or additions are possible. In particular, further featuresand/or variations can be provided in addition to those set forth herein.For example, the implementations described above can be directed tovarious combinations and subcombinations of the disclosed featuresand/or combinations and subcombinations of several further featuresdisclosed above. In addition, the logic flow(s) depicted in theaccompanying figures and/or described herein do not necessarily requirethe particular order shown, or sequential order, to achieve desirableresults. Other implementations may be within the scope of the followingclaims.

1.-18. (canceled)
 19. A method of infusing at least one drug or fluid toa patient comprising: receiving instruction to initiate an infusion ofat least a first drug and a second drug to a patient by an infusiondevice, the infusion device comprising at least one programmableprocessor and memory storing instructions for execution by the at leastone programmable processor; determining, by the infusion device, thatthe infusion device is transitioning from a first care area to a secondcare area; comparing at least one of the first drug and the second drugto a list of drugs that are allowed to be infused in the second carearea; determining, based on the comparison, that the second drug is notsuitable for use in the second care area; activating an alarm to notifyan end user that the second drug is not suitable for use in the secondcare area.
 20. The method of claim 19, wherein each of the first carearea and second care area is associated with drug parameters related toat least one of the first drug and the second drug.
 21. The method ofclaim 20, further comprising accessing a list of care settings for ahospital in which the infusion device is located, the list of caresetting including at least one of a first drug parameter and a seconddrug parameter.
 22. The method of claim 19, wherein comparing at leastone of the first drug and the second drug to a list of drugs that areallowed to be infused in the second care area is initiated in responseto the infusion device transitioning from the first care setting to thesecond care setting.
 23. The method of claim 19, further comprisingdetermining that the infusion device is transitioning from the secondcare area in the hospital to a third care are in the hospital.
 24. Themethod of claim 23, further comprising comparing at least one of thefirst drug and the second drug to a list of drugs that are allowed to beinfused in the third care area.
 24. The method of claim 19, whereintransitioning from a first care area to a second care area comprisesphysically moving from the first care area to the second care area. 25.The method of claim 19, further comprising allowing infusion of thefirst drug in the second care area.
 26. The method of claim 19, furthercomprising stopping any infusion of the second drug.
 27. The method ofclaim 19, further comprising prompting a user as to whether to stopinfusion of the second drug.